The use of digital signatures to certify the authorship of a software file is a procedure widely adopted by leading companies in development and distribution of software. Adopting digital signatures involves the integration of a complex infrastructure in code development environments and operating systems where this code will be run. Certainly, the use of signed software prevents multiple threats defined for the generation and distribution of software; however, as it also involves the incorporation of new components and services, it is possible to identify new threats that might affect the signature process itself.
The key element of this infrastructure is the use of public key cryptography. It enables designers to maintain signing processes and signature verification processes independently, without the need of a prior exchange of secret keys. The independence of these two processes facilitates the establishment of a classification for categorizing threats according to the process for which they are defined. The theft of certificates (with the compromise or uncontrolled exposure of the associated private key), improper use of certificates, inadequate policies for certificates update and problems in the certification chain (breakage or modification) are the sources of several threats that affect both processes, although the objectives pursued are different whether the signing process or the verifying process is attacked.
Cryptography efficiently responds to the need for extremes identification in any communication process. Different cryptographic mechanisms have been defined to accomplish this task, but the most extended is the use of digital certificates. These are built based on public key cryptography. The task of identifying the extremes is assumed by Certification Authorities (CA), which are in turn identified, by such extremes, as trusted entities. It is necessary that who is behind the public key contained in a given certificate has been identified properly by the certifying authorities. It is also required that a particular certification authority can be identified using its own public key. A correct identification can be accomplished only if these two requirements are satisfied.
Although the digital certificates are crucial in website identification, they are also the key elements in signing processes. Certificate management has to be coherent with an adequate Public Key Infrastructure to provide protocols for implementing the processes related with file signing (code signing). A pair of keys, one public and one private is generated for each user or entity for encryption and decryption. As stated before, to ensure the trustworthiness of public/private keys, certificate authorities (CA) issue digital key certificates. These certificates are signed digitally by de CA to guarantee that an individual providing a digital certificate is who the individual claims to be. By issuing the certificate, a CA is asserting that the content of the certificate applies to the certificated subject. When the certificate subject presents the certificate to relying parties, the relying parties can use digital certificates to authenticate the certificate subject. This certification is valid until the expiration date specified by the CA. If the certificate is not expired, the authentication process typically involves two phases: first, the integrity validation of the certificate using the CA's public key, and second, verifies that the certificate's subject has access to a private key associated with the subject's certificate.
Sometimes, digital certificates may need to be revoked prior to expiry, for example when the privacy of the subject's private password has been compromised. The revoked certificate is then published in a certificate status information database administrated by CA, such as Certificate Revocation List (CRL). When a relying party uses the certificate to authenticate a certificate subject, the relying party may determine the revocation status of the certificate by directly accessing this certificate status information database. However, the CA architecture is a purely centralized solution. High latencies and availability problems occur frequently. In order to eliminate the need for connectivity with the PKI when the relying party need authenticate the certificate subject's identity, one approach allows for each certificate subject to periodically acquire its status from CRL or to obtain an OCSP status for its certificate subject from an OCSP Server. These solutions inherit the availability problems cited above, causing problems with the revocation information actualization [1]. In 2012, Google Inc. proposed to migrate the information contained in the CRL to the browser [2]. This means to leave the traditional centralized schema for a distributed schema, eliminating the bottleneck that the prior OCSP servers or CRL server are being.
Actually, code signing is a particular important application of these digital certificates. Code signing process consists in digitally signing executables and other files that can be interpreted by a runtime platform to ensure that these files have not been altered. Now it is possible to identify a code as coming from a specific source and to determine whether code is trustworthy for a specific purpose (FIG. 1). There are two main methods to code signing: developers/distributors can choose to provide their own self-generated pair of keys (private/public) and they have to provide the public key to the user somehow as disclosed in U.S. Pat. No. 7,370,206; or the public key used to authenticate the code signature should be traceable back to a trusted root authority CA using a secure PKI. Even the second method does not ensure that the code can be trusted; this method only ensures that the code was signed by the subject of the certificate. A CA provides a root trust level and is able to assign trust to others by proxy. If a user trusts a CA, then the user can presumably trust the legitimacy of code that is signed with a key generated by that CA or one of its proxies. Many operating systems and frameworks contain built-in trust for one or more existing CAs. Typically, a code signature consists of three parts:                A file digest, which is a collection of checksums or hashes of the various parts of the code. The digest can be used to detect alterations to the code and to the application identifier.        A digital signature, which is performed by the legitimate user with his or her private key and is used to sign the digest to guarantee its integrity. Therefore, the signature includes information that can be used to determine who signed the code and whether the signature is valid.        A unique identifier, which can be used to identify the code or to determine to which groups or categories the code belongs to.        
Like any security measure, code signing can be defeated. Users can be tricked into running unsigned code, or even into running code that refuses to validate. It is also important to note that code signing does not protect the end user from any malicious activity or unintentional software bugs made by the software author [3]. Unfortunately, not even the correct use of software signatures can protect end users. If you cannot ensure that there is no security breach in the whole signing process, it has to be assumed that the resulting software may have been compromised. This means, among other security breaches, that the digital certificates integrity and the signed file integrity can be broken.
The targets wanted by an attacker of a signing software system are:                Cheat the signer to sign a file different than the intended one or under not intended conditions changing the rules or policies established in the signing requirements.        Unauthorized access to the signature creation data.        Replace the signed information. The attacker attempts to replace part or all of the information signed by their own benefit when the file signature has been calculated        Make the signed file be attributed to a user different than the actual signer. The attacker seeks that a file signed by certain signer is verified as signed by a different entity. Thereby, the attacker could cause a wrong file's authorship attribution.        Make the signed file attributed to a different user than legitimate user. The attacker seeks that a file signed by the legitimate signer is verified as signed by a different entity. In this way, the attacker could cause the incorrect attribution of authorship of a file.        Make the file to be Verified contents chosen information. The attacker seeks that the signed file is shown to the verifier either with a content which appearance may be different to what was actually signed.        Make the signature verification conclude with an opposite result. The integrity of the signature depends not only on the signature itself but also on the certificate validity.        
To reach these targets multiple attack techniques can be documented. A complete classification for them is showed in table 1 formulated in seven different categories [4]:
TABLE 1Threats defined for the signing process and signature verification processes.Manipulation ofDocumentDynamic contentHidden Codethe environmentModificationinclusionActive Codeof execution ofLinked Codeboth processes.ContentModificationAttributeDynamic ContentHidden CodeModificationInclusionActive CodeLinked ContentContentModificationData to be signedmodificationData to be signedrepresentationModificationModificationExternal Contentbefore theCryptanalysisHash FunctionCollision AttacksignaturePre-Image Attackcalculation.Second Pre-imageattackModificationCompromise of theSocialbefore thesignerEngineeringsignatureauthentication dataSignerObservationcalculation.AuthenticationInterception inData Interceptioninterprocess/entitiescommunicationEndpoint compromiseGuessingAuthenticationBypassCompromise ofSignature CreationInterception in interprocess/entitiesthe data used inData Interceptioncommunicationthe computationEndpoint compromiseof the signature.EavesdroppingTiming Analysis(side-channel)Electromagnetic analysisPower analysisMicroarchitectural AnalysisOptical observationUnauthorizedCompromise of the signer authenticationaccess to theDataSignature CreationAuthentication BypassDevicesCryptanalysisAsymmetric AlgorithmInvasive tamperingattacksTampering withAlteration ofthe result of thesubscriber'scertificatesrevocation requestverification.Alteration ofGrace orDelay in time-stampedcertificate statuscautionary periodsignature sendingverificationbypassingDelay in time-markedsignature sendingExploit delay in CA'srevocation requestprocessingModification ofModification of OCSPcertificate statusrequestverificationModification of LDAP-requestbased requestModification ofcertificate statusverificationresponseAlteration of timeModification of time-referencestampverificationModification of timemarkValidationOCSP Response replyinformation replyAlteration ofcertificate statusverification resultUntrusted trustanchorAlteration ofcertificate integrityverification resultAlteration ofcertificate validityperiod verificationresultTampering withPresentationData to beDocumentthe result of theManipulationverifiedmasqueradingsignaturemasqueradingAttributeverification.masqueradingViewerViewer substitutionmanipulationAlteration of viewer'sbehaviorVerification resultmasqueradingPolicy substitutionElectronicsignature policysubstitutionCertificate policysubstitutionAlteration ofInjection ofverificationsignature-signedprocessdata pairAlteration ofcryptographicverification resultAlteration of finalverification result
Causing an environment manipulation or achieving a modification before the signature computation an attacker can deceive the signer to sign a document different than the intended one or under unintended conditions. Performing an unauthorized invocation of the signing function or compromising of the signature creation data can suppose an unauthorized use of signature creation data. A modification after signature computation will cause a replacement of signed information. Tampering with certificate verification result or signature verification result can attribute the signed document authority to a different user than the legitimate signer. By other hand, an environment manipulation, joined with an influence on signature verification result, can make that the data to be verified will be shown with maliciously modified content. Finally, tampering with certificate verification result and/or tampering with signature verification result can make the signature validity verification conclude with an opposite result.
In table 1 has been shown that, leaving apart the manipulation of the environment of execution of signing and verifying processes, all the categories contain threats related with security problems derived from the misuse of digital certificates. All these threats are marked in table 1 and can suppose the implementation of different types of attacks: Improper issuance caused by an incorrect CA parsing; incorrect browser parsing of the digital certificates; Man in the Middle attacks; rebinding attacks; abuse of trust anchor information in certification validation paths; Digital Certificate Theft, etc.
Some of the existing solutions for several of these attacks have been described above but there are other solutions that need a deeper analysis. In 2007, the certificate authority industry developed a technology named extended validation certificates (EVC) in order to improve the security in the issuance of certificates. Unlike normal certificates, which indicate only that the owner controls a particular domain name, extended validation certificates also confirm to the identity of a legitimate business. Special mention is needed for the solutions provided to solve the abuse of trust anchor information and the Man in the Middle attacks using a technique called certificate pinning. EMET is a tool developed by Microsoft as a protection software suite which contains solutions for different security problems. One of these solutions provides a technique that proposes to join internet domains with certificates issued by root certificate authorities present in the user's trust certificate store. Another option is provided by Google, who proposes to modify the web browser (i.e. Chrome). Chrome has added to its source code some web sites that will always work with HTTPS active from the beginning. These web sites are called “preloaded HTST sites”. In addition of requiring the use SSL protocol from the start of the connection, the Google's browser will remember what public keys are known and it will reject the rest, even if the user doesn't write down https in the browser's address bar. The data of the authorities in which Google usually trusts are included in source code of the browser (VeriSign, Google Internet Authority, Equifax and GeoTrust).
However, the solutions provided to overcome the attacks based on abusing of trust anchor information and the Man in the Middle attacks have several problems that nowadays remain unsolved. Despite they have improved the availability problems related with OCSP and CRL, they have been designed to operate with the web browser by associating web domains to digital certificates and there is noMic opportunity to employ this certificate pining to verify the signature of software files at all. By other hand, the use of extended validation certificates can be compromised by rebinding attacks. Neither the extended validation certificates nor the certificate pinning solutions can do anything to avoid the theft of them.
Digital certificates present in the binaries files of a software product are designed to guarantee the integrity and the authenticity of these files. Several reasons exist to prove why an attacker may need to use illegitimated acquired certificates to sign his own code.                The antivirus solutions usually award higher trust level to files signed by trusted authorities.        The final user (or the victim) trusts the signed files because signature independently of the origin of the certificate used. Also a contributing factor is the fact that verifiers programs are integrated with the operating system user account control to codify with colors the trustiness of a file (e.g. Microsoft UAC): Green color corresponds with a trusted and signed file.        In modern operating systems, correct digital signature is required to perform some tasks, as device driver's installation. If an attacker wants to penetrate in the system in a silent manner, he needs to sign his rootkit with a valid certificate.        
Currently, when a stolen certificate is detected, the owner requests its revocation. This revocation implies to publish it in black list but this process presents several inconvenient:                When the theft of the certificate is detected, it is impossible to know for how long this certificate has been in possession of the attacker.        In the case of signing software, the certificate revocation is not always possible because the signed binaries files might not work properly.        There are problems related with delays in the information update from the CRL and OCSP blacklists.        
So, there is no solution to defend an end user of signed binaries or software files from the abuse of digital certificates or the compromise of the trust chains associated with them. Therefore, the present invention provides a solution to mitigate the effect of theft certificates and compromised certificate authorities. The invention allows the user verify the integrity of a given file.